POV：你剛把一隻 bot 搬進 k3s、也修好了 CrashLoopBackOff，正想把手上其他東西全搬上去，然後想起那台 Spot VM 上的 compose 其實跑得好好的。
Week 3 花了五天讓一隻 bot 活在 k3s 裡。Week 4 要退一步問一個更誠實的問題：對你的 AI app 來說，K8s 是正確答案嗎？我自己的答案是「有時候不是」，而且我有一個真實案例（Day 17）是評估完決定不搬的。今天先把決策樹畫出來。
我一開始以為部署方式是一條從簡單到複雜的光譜，後來發現它們更像四個不同的房間，各自有適合住的人：
四個房間的價格、限制、要顧的事都不一樣，而且不是「越後面越好」。
Q1：你的 agent 是「一直在」還是「有人叫才動」？
Discord bot 這種自己維持連線、隨時等事件的，是一直在；提供 HTTP API 給別人 call 的，是有人叫才動。我的 LINE bot 嚴格說屬於後者：它是 LINE 的 webhook 走 cloudflared tunnel 打進來（Day 05），只是我目前還是讓它常駐在 compose 裡，這題答起來要看你怎麼接事件，不是看它叫 bot 就算一直在。前者跟 serverless 容器的 scale-to-zero 天生衝突（Day 21 會細講），後者是 serverless 的主場。這題我在 Day 17 會示範一次答錯的經驗：看起來是 HTTP 服務，骨子裡卻有背景工作跟記憶體裡的狀態。
Q2：你有幾個服務、它們之間有沒有依賴？
一隻 bot：房間 1 就夠。bot 加 RAG 引擎、向量庫、反向代理（我的 devstack 就是這樣）：房間 1 還撐得住，但你會開始感受到 Day 04 那種什麼都疊在一台機器上的壓力。要超過一台機器才放得下：房間 3 或 4。需要各自獨立擴縮但每個服務都是有人叫才動的 HTTP 服務：房間 2 也做得到，每個服務各自是一個 service 各自 scale，不一定要進 K8s。
Q3：你需要 GPU 嗎？
需要的話，房間 2 和 3 都有 GPU 選項（Cloud Run GPU、GKE GPU node pool，Day 25 講），但計費模型差很多。自架 GPU 節點（房間 4）在 side project 規模，我目前的判斷是通常不划算。
Q4：你願意花多少時間在顧叢集，而不是寫 agent？
這是最誠實的一題。房間 4 自由度最高，代價是升級、備份、節點壞掉都是你的事（Day 29）。房間 3 把 control plane 外包了，但 YAML、網路、權限還是你的。房間 2 幾乎什麼都不用顧，代價是限制多，Day 17 會撞到一道很具體的牆。房間 1 最省心，直到機器掛掉。
Q5：你的機器會不會被回收？
如果你像我一樣用 Spot VM 省錢，房間 1 的省心就要打折：重開機後誰把東西拉起來？容器靠 restart policy 可以自己回來，但機器上其他沒宣告在任何設定檔裡的東西，要靠自己寫的腳本，而那些腳本不一定每次都對（Day 18 有實錄）。房間 3 在這點有結構性優勢：節點掉了，Pod 可以排去別的節點，前提是你真的有別的節點。單節點的 k3s（房間 4）在這題上跟房間 1 一樣，得等機器回來。
誠實講：我大部分東西在房間 1。OpenAB 的十餘個容器跟 devstack 都是 docker compose 起的，liaostudio 用 systemd 顧著（Day 17 會講），都在同一台 Spot VM 上。少數 GPU workload 在房間 2：liaostudio 的自架 Whisper backend 跑在 Cloud Run L4。房間 4 是我的學習沙盒，Week 3 那隻 bot 就住在那裡。房間 3 在這個系列裡我還沒把任何東西搬上去，Week 5、6 會做最小實作，但那是「試」不是「搬」。
這個系列叫筆記而不是指南，就是因為我自己也還在這棵樹上移動。
我看過（包括我自己）的一個錯誤是：因為想學 K8s，就把跑得好好的東西搬上去。結果是多了一層要顧的東西，agent 本身沒有變好。Day 11 講的學習路徑刻意把沙盒跟生產分開，就是為了避免這個。要學，在 k3s 上學；要搬，先走完這棵樹。
另一個反過來的錯誤是：因為房間 1 現在還撐得住，就假設它永遠撐得住。Day 04 的 swap 見底跟 Day 18 的重開機，都是房間 1 在提醒我它的邊界在哪。
明天講一次我真的走完這棵樹的經驗：評估完 Cloud Run，決定暫不搬。
K8s 不是部署的終點，是四個房間之一。先問你的 agent 是一直在還是被叫才動、你願意花多少時間顧叢集，再決定要不要進這個房間。
iThome鐵人賽
看影片追技術